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1. Introduction. 


The Space Station Freedom will offer facilities for experimentation and testing 
not available and not feasible or possible on earth. Due to a restricted space availabil- 
ity on board, the experimentation equipment and its organization will be frequently 
changing. This requires careful attention to electromagnetic compatibility between 
experimentation and other SSF equipment. To analyze the interactions between 
different equipment modules, a software system ISEAS [6] is under development. 

Development of ISEAS was approached in two phases. In the 1st phase a PC 
version prototype of ISEAS was developed. In the 2nd phase, the PC prototype will 
be adapted to a VAX range of computers. The purpose of this paper is to review the 
design of the VAX version of ISEAS, and to recommend any suitable changes. 

2. Architecture of ISEAS. 

ISEAS consists of the following components: interactive interface, analysis 
module, output module, and data base containing data used by analysis routines. 
ISEAS user communicates via the interface his requests for analysis instances, types 
of analysis result displays, and supplies appropriate data. The interface will be 
implemented using ORACLE/SQL relational database environment running on a 
VAX platform. User’s requests are passed to the control module which performs the 
analysis. The analysis routines will be implemented in C. The output module offering 
different ways of result’s presentation will be implemented in Fortran. The data base 
will be created using the services of the ORACLE/SQL running on a VAX platform. 

3. Design methodology 

ISEAS is to be developed using a structured software approach [3, p.4]. Struc- 
tured methodology offers a methodical approach to development, yielding good 
system design, correct and efficient data model, smooth implementation, and a basis 
for ease of maintenance. The methodology spans a whole software life cycle which 
consists of essentially sequential phases: Project initiation, Requirements elucidation, 
Feasibility study, System Analysis, System Design, Implementation, Testing, Installa- 
tion, and finally System Review. Once fielded, the System Maintenance follows. 

The review is limited to Analysis and Design Stages. The purpose of the Analysis 
stage is to consider what is to be done and what are the system’s data requirements, 
while the purpose of the Design stage is to consider how it is to be done. 

3.1 Deliverables 

At each of the Software Life Cycle stages, structured software methodology 
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predicates a number of deliverables. The System Analysis stage requires the following 
deliverables: 1) Context Diagram which presents a top level design of the system 
addressing its purpose and main functions, 2) Data Flow Diagrams which present 
processes within the system, functions that system will perform, and flow of data as 
these processes and functions are invoked, 3) Data models expressed via Entity 
Relationship Diagrams (ERD) which present the various data entities and relation- 
ships that are recognized by the system, 4) Decomposition Diagrams which present 
the logic of the system through hierarchical structure of the modules of the system. 
The System Design stage requires: 1) Transition Diagrams which present a reorga- 
nized Decomposition Diagrams after taking into account the module types in addition 
to their functionality, 2) Structure Charts which present the structure of system 
modules and their data interfaces, 3) Pseudocode or Action Diagrams which present 
the actions defining the modules. 

3.2 Data Normalization 

A Relational Database consists of data items, relations among them and opera- 
tions that can be applied. Whereas "primitive" operations are defined by a chosen 
relational database -- in ISEAS case it is ORACLE -- definitions of relations are left 
to the system designers. To assure efficiency, to avoid data redundancy and inaccessi- 
bility, to protect against data loss, etc., the data must be normalized. It is a common 
practice to expect the relation tables to satisfy at least the first three (Codd) Normal 
Forms which present essentially steps for relationship transformation with the aim of 
assuring elimination of various anomalies (in particular data modification anomalies). 

4. Review findings 

The following summarizes review findings. A more detailed exposition can be 
found in [Bykat, 1993]. 

[3] presents ERD, Structured Charts, and Pseudocode. Omission of the other four 
items results in missing documentation of modules, inconsistencies, and possibilities 
for module design improvement. There are violations of the Structured Charts 
presentation semantics. Pseudo-code for a number of modules is missing. 

Database table are presented but show violations of the first three normal forms. 

Backup requirements as well as requirements concerning support of local and 
remote users [2, p.53] have not been addressed. 

5 Conclusions. 

ISEAS is a needed and timely project. The proposed version offers fundamental 
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capabilities but requires further technical (EMC) development and evaluation of the 
offered capabilities and their functionality. In particular, current calculations view the 
equipment and their components as "point sources". The size of the equipment, the 
location of a component within the equipment are not taken into consideration. 

EMC analysis recommendations are essentially diadic: pass or fail. This could be 
addressed by calculations for repositioning the equipment to find a location in which 
initially failing equipment would pass the EMC criteria. A further extension would be 
finding optimal configuration of a given equipment for EMC purposes. 

6 Recommendations. 

The recommendations fall into three categories. The first category relates to the 
strategy of ISEAS development, the second category relates to technical issues, while 
the third category presents a path for further development of ISEAS. 

6.1 Strategy. 

The main goal of the ISEAS project is to provide a tool for evaluation and 
analysis of EMC for the Space Station Freedom. This goal should be enlarged to 
"provide a tool for evaluation and analysis of EMC for the EMC community at large 
and for the Space Station Freedom in particular". 

There are a variety of applications where ISEAS (or its descendant) delivered on 
a workstation platform would be of considerable benefit. Many of these applications 
are in commercial areas (aircraft manufacturers, land/water-based vehicle manufactur- 
ers, etc.), while other are in government agencies (Navy, Air Force, etc). In such 
applications EMC considerations are important, if not critical (eg. interference with 
navigational equipment, etc.). 


NASA is now at crossroads, searching for ways serve broader national needs". 
This will lead the agency towards much greater involvement in private sector through 
attempts to "push technology through the federal door and into commercial market- 
place" 1 . Such involvement has to be contemplated and planned a priori rather than as 
an afterthought. ISEAS offers an opportunity for such involvement. 

I recommend therefore development of a VAX version in parallel with development 
of a workstation version of ISEAS operating in a multitasking Unix environment 
supporting XI 1 windowing environment, and with a suitable relational database. 


1 speech by Rep. Alan Mollohan (D-W.V.) delivered at the 31st Goddard Memorial 
Symposium, 3/9/93 (Space News, 6/14/1993, p.19) 
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6.2 Technical. 


Rl. Develop Data Flow Diagrams and Decomposition Diagrams. Revise and com- 
plete Design Phase documentation. Gain: Lead to correct structure of the system. 

R2. Complete the normalization of data. Gain: Avoid data modification anomalies. 

R3. A user interacts with ISEAS in two distinct modes: define and select. ISEAS code 
should adopt the same philosophy in presentation of forms and screens for da- 
ta/request entry. Gain: ISEAS code will be much shorter and much more efficient. 

R4. Partial description of entities during data input should not be accepted by ISEAS. 
Gain: ISEAS code will be much shorter and much more efficient. 

R5. Before the input of new data affected files should be preserved as prior versions. 
Gain: efficient restoration of prior version. 

R6. Extend analysis selection capability to allow any combination of analyses to be 
performed. Gain: Batch mode execution of analyses. 

63 Future development 

An intelligent object oriented interface for ISEAS should be developed to offer 
ease of use and functionalities which current version lacks. It should offer a graphical 
mouse-relocatable component and connectivity icons to aid graphical environment 
data input, visual validation, and reconfiguration of analyzed environments. It would 
allow improved presentation of results through a 2-dimensional "interference regions", 
easing subsequent graphical modification of equipment configurations. 

Electro-magnetic compatibility analysis is a ripe candidate for further automation 
through knowledge based methodology [4, 5]. Development of EASE-MagIC, an 
Expert Analysis System of Electro-Magnetic Interference and Compatibility, would 
serve this purpose. Such a knowledge based system can offer evaluations controlled 
through heuristic rules, on demand instructive explanations of the analysis and its 
conclusions, and through such explanations - coupled with the proposed graphical 
interface - it would offer a sophisticated tool for EMC training. 
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